docs: require that a stated verification result was actually produced - #132

Closes #131

What this adds

One bullet under Key Principles, next to Library-source-first debugging:

Never state a verification result you did not produce (mandatory) — every factual claim written into an issue, PR body, plan, commit message or review must come from a command actually executed in the session that writes it. If a check was not run, run it or omit the claim; an unrun check must never appear in the past tense.

Plus two habits underneath it: run the positive control before concluding absence, and verify claims about this repository the way you verify claims about a library.

Why it is written down rather than assumed

Issue #126, since deleted, reported that SDLC.md "has never existed in the repo" on three grounds. Two were never executed and were false. SDLC.md was present at 7,652 bytes, tracked by git, added in 89b7361 on 2026-06-21 and revised six times, most recently aabd5b5 (PR #79). The third ground was executed and inverted: git log --diff-filter=D -- '*SDLC*' returning nothing proves the file was never deleted; --diff-filter=A returns the adding commit on the first try.

The mechanism worth naming is that nothing caught it. A fabricated claim is indistinguishable from a measured one to every later reader, so it passed through a plan, an explicit approval given on the strength of those claims, a filing, a work item and a close — and surfaced only when the file was independently opened. The cost compounded: #126 also argued no documented fast path existed for a docs-only change, while SDLC.md § Fast Paths already carried one, and its Dependabot fast path already stated the rule that #124 / PR #125 went on to follow by coincidence rather than by reading it.

The alternative, and why it lost

Leaving it undocumented was argued on the grounds that verifying a claim before asserting it is baseline conduct rather than a project convention, and that a rule written after the fact supplies a citation for the next occurrence instead of preventing anything. That objection is sound in general and is recorded in #131 so it does not have to be re-argued. It does not apply here: the behaviour was demonstrably treated as optional, and the evidence against "too obvious to write down" is the incident that raised the question.

Verification

Documentation only — no code, no CI, no dependency change. The claims in this PR body were produced by git log, git ls-files and wc -c against main at 85eaedf before it was written.